1. Field of the Invention
The present invention generally relates to the field of client/server data systems. More particularly, the present invention relates to the field of exporting and importing information with respect to two or more computer systems wherein one computer system is a handheld electronic device.
2. Related Art
Computers and other electronic devices (e.g., personal digital assistants) have become integral tools used in a wide variety of different applications, such as in finance and commercial transactions, computer-aided design and manufacturing, health care, telecommunication, education, etc. Computers along with other electronic devices are finding new applications as a result of advances in hardware technology and rapid development in software technology. Furthermore, the functionality of a computer system or other type of electronic device is dramatically enhanced by coupling these stand-alone devices together in order to form a networking environment. Within a networking environment, users may readily exchange files, share information stored on a common database, pool resources, and communicate via electronic mail (e-mail) and via video teleconferencing. Furthermore, computers or other types of electronic devices which are coupled to the Internet provide their users access to data and world-wide information.
A personal digital assistant (commonly referred to as a PDA) is a palmtop computer system. It is appreciated that the personal digital assistant is a portable hand-held device that is used as an electronic organizer which has the capability to store a wide range of information that includes daily appointments, numerous telephone numbers of business and personal acquaintances, and various other information. Information within the handheld device is processed using various application programs (“applications”).
FIG. 1 illustrates a prior art system 5 in which a handheld device 6 can communicate with another computer system 7 to import and export information using a communication link 15. In this system 5, each application 8a-8c, on the handheld computer contains its own database and its own custom conduit program 10a-10c that is used to facilitate information exchange between the handheld 6 and the computer system 7. The conduit programs examine the databases on the handheld 6 and on the computer 7 to determine which data to exchange between these systems so that each database contains the same information, e.g., so they can be “synchronized.” An installer application 12 can be used, during synchronization, to install new applications and databases onto the handheld 6.
In order to transfer data from one computer system to the other, a developer of the application can generate a custom conduit program to facilitate the information exchange for the application. However, the conduit mechanism is very complex and difficult to implement. Further, different conduits are required for different host operating systems thereby making the conduit mechanism even more difficult to implement. Full synchronization of data between the device 6 and a host computer system, e.g., “PC” 7 is difficult to implement, and many applications do not really require it. A great number of applications do not need to keep two copies of a database in synchronization. What they do need to do, however, is to export/import data with the desktop 7 and the rest of the world.
However, the synchronization model 5 of FIG. 1 does not provide an easy way to send data directly to or from the device 6. System 5 requires developers to write a desktop application with its own database and a conduit to synchronize that data with the device. They can then import data into the desktop application and synchronize that data to the device. Alternatively, within system 5, a user can import applications or databases (having the extentions .PRC, .PDB and .PQA) using the install utility 12, and a user can backup or restore databases using the backup conduit 10d. However, to do anything more than this requires that the developer make a specific conduit for their application. The skills and knowledge required to write a conduit are separate from those required for writing other PDA operating system applications. Conduits are written with different tools in a different language (C++) using a different operating system (e.g., Windows). In addition to the efforts involved in writing a conduit, there are the support issues. Conduits require an installation utility, complex documentation, and special operating system specific technical support for both the handheld device 6 and the computer system 7.
Many developers try to avoid conduit development and various methods have been used to avoid conduit development. The most common one is to import data as whole databases using the install utility 12. To do this, a database image (e.g., .PDB file) is created and then the import data is placed into the database image. This allows applications to load data (using the .PDB extensions) into their applications on the device without writing a conduit. Document and image files are common examples of this. However, there are several problems with the “whole-database” approach. The first is that desktop developers are forced to create database files using internal database header and record formats native to the handheld 6. This is unnecessary overhead for the content and can lead to compatibility problems if anything in the format ever changes, e.g., future handhelds use different internal formats. Further, most of these file formats were originally reverse engineered from content that may not have been documented. Another problem with this approach is that it requires each import data to be first translated into a database image (e.g., .PDB file) before it can be installed. This prevents users from installing data encoded in otherwise universal file formats unless they first perform the bothersome translation. Another problem with this “whole-database” approach is that the operating system on the handheld device 6 is designed to work well with many records in few databases. Instead this method requires applications that have many databases, each representing one data item, e.g., a document or an image. This approach is very inefficient in terms of computer resource usage.
Furthermore, many features of the handheld's operating system that are developed for record processing cannot be applied to individual databases which are treated as “records.” For instance, the database manager of the handheld 6 is designed to sort records, not databases. Also, the launcher of the handheld 6 was not designed to work well with large numbers of database files. Furthermore, the synchronization software manager is record based for tracking deleted, modified or archived records. These types of functions are limited when an application manages data by the database instead of by the record. Moreover, this method is limited because once a database is transferred to the handheld device, it becomes registered with only one application.
In other approaches, users have utilized the backup conduit 10d and the memopad conduit to install data files on the handheld 6. The backup conduit 10d backs up entire databases, but there is no other synchronization support in this area. Some developers have used the backup conduit 10d as a way of exporting data to the desktop. Other applications resort to importing data via the memopad application. These applications will use a category in the memopad as an identifier for memos that belongs to their application. This allows them to rely on the built-in synchronization provided in the memopad application. Unfortunately, these methods are very complex for most users to perform and they also clutter the memopad with data that the user has no need to read and forces their applications to read and write directly to the memopad's databases. What is needed is a better method and system for users and developers to be able to import and export data to and from the handheld device 6.
Alternatively, today a software program, the exchange manager, can take PC based files and import them into the correct application on the handheld device using the infrared beaming functionality of the handheld device. In the exchange manager, records beamed from the handheld device end up as files in an inbox on the PC. However, most people do not have the appropriate infrared setup on their desktop computers to utilize the exchange manager in this fashion. Therefore, this solution is not widely accepted. What is needed is a better method and system for users and developers to be able to import and export data to and from the handheld device 6 that uses a communication protocol and specification consistent with most computer systems (PCs).
In addition, there may be instances where an application is aware of the destination of some information that is to be exported and the application may even be aware of the transport mechanism best to export the information. In these instances, the applications themselves must be customized to practice the desired export functionality. In other words, there is no universal mechanism for allowing applications to export information using their own specifications. There is no universal mechanism that is flexible, e.g., allowing ready modifications and changes in the desired destination and transport mechanism. There is no transparent mechanism to perform these tasks.